FIG. 1 illustrates a conventional classloading method in virtual machine (VM) environments, for example Java® Virtual Machine (JVM®) technology environments. As indicated at 100, a request to load a class is obtained by a classloader. As indicated at 102, the classloader may delegate classloading to a parent classloader, which may, but does not necessarily, load the class. As indicated at 104, if the class was not loaded via delegation, the classloader searches its class path (for example, specified as a URL) to find the requested class, as indicated at 106. Typically, the class will be specified as a class file in a class file container (e.g., a Java® Archive (JAR) file) specified by the class path. As indicated at 108, the classloader may perform security checks on the class/class file. As indicated at 110, the classloader then reads the class file (e.g., from the JAR file) and at least partially parses the class file to verify the class format. Note that element 110 may not be performed if verification is not needed or disabled. As indicated at 112, the classloader may then read and parse the class file in more detail to create VM internal metadata structures for the class. As indicated at 114, the classloader may then create the class instance. At 116, class linking is performed. Class linking may include linking the class to a superclass, generating a method table based partially on the superclass, and determining object layout based partially on the superclass. At 118, the class is made available in the VM environment. In some implementations, this may involve adding the class to a class table and the classloader's class vector.
In conventional classloading methods, constant pool resolution typically happens lazily (on demand) after the class is loaded and linked. During execution of a class, constant pool entries are resolved on first references.
However, the conventional classloading method tends to be relatively slow as it involves looking up and reading class files from class file containers, creating VM internal data structures for the class metadata, and so on. In addition, constant pool resolution tends to be slow, and needs to be performed each time a class is loaded. Classloading performance can thus have a significant negative performance impact on applications, especially at startup. On systems such as embedded systems or mobile devices that may have relatively limited processors and/or relatively slower I/O operations, the impact of classloading performance becomes even more significant.
Java and JVM are trademarks or registered trademarks of Oracle, Inc. and/or its affiliates in the United States and other countries.